Modern Internet and web applications commonly require information about the user and user's activities to be maintained across multiple requests. For example, in a typical online store, the user is provided with a browseable catalog from which items can be selected and added to a shopping cart. Once the user has added all the desired items to the shopping cart, the user may proceed to the checkout where an order for the items contained in the shopping cart may be placed. To accomplish this process, multiple client requests are required and the information from each request must be maintained across requests.
A hypertext transfer protocol (HTTP) is used to access many resources on the Internet. However, HTTP is a stateless protocol that defines the format of requests and corresponding responses but does not currently define a mechanism for maintaining state information. In a typical request, an HTTP user or client opens a connection with a server and requests some information or a resource. The server responds with the requested resource, if available, or an HTTP error status page. After the server's response, the connection is closed and the server does not maintain any information about the client. Any subsequent request by the client is considered a fresh request with no relation to the previous request.
Several approaches have been developed to maintain user information across requests and responses. These approaches use the notions of sessions and states. A session is a series of HTTP requests originating from the same client in the same browser instance or “working session.” State refers to information relating to the previous requests and other business decisions that may be made in relation to these requests. Utilizing these approaches, an Internet or web application should be able to associate a state with each session. Two common methods of session management are cookies and Universal Resource Locator (URL) rewriting. Cookies and URL rewriting are known in the art. Other session management strategies are also known in the art. Generally, session management strategies use an associated session area to store information about the user session.
Many modern Internet and web applications are modular in design. Modularity allows different aspects of an application to be developed independently from one another. The Model-View-Controller (MVC) design pattern is a common design paradigm used in developing modular applications. The MVC design pattern is known in the art.
In many Internet and web applications, a user will typically have to navigate through a number of organizations. These organizations may be located in different domains. For example, in an electronic marketplace or e-marketplace environment, a buyer in a supply channel may move between a manufacturer or supplier and distributors or resellers. Each of these organizations is referred to as a store. Each store will typically have its own commerce context, for example, a store context. Thus, when navigating between stores, it is necessary to manage the switch between store contexts. A simple shopping flow illustrates this problem.
A typical shopping scenario for a supply channel may involve the following steps:
(1) A buyer visits the channel store main page;
(2) Browses through the catalog;
(3) Places an order for a product;
(4) Receives a confirmation for the order;
(5) Continues browsing for other products.
The process steps described above may be given the following names:
Step (1)—StoreFrontDisplay
Step (2)—ProductDisplay
Step (3)—OrderProcess
Step (4)—OrderDisplay
Step (5)—ProductDisplay
In this shopping scenario, the buyer moves back and forth between the channel and a supplier store. In step (1), the StoreFrontDisplay displays the main page of the channel store. In step (2), ProductDisplay involves retrieving the product(s) from the catalog of the channel store and rendering the product description(s). In step (3), OrderProcess involves placing the order in the supplier store. In step (4), OrderDisplay retrieves the order and displays the order. This step can be performed in the channel store or the supplier store. In step (5) ProductDisplay, the buyer is in channel store browsing products from the catalog.
To create a smooth shopping experience, there needs to be a way to manage the switch between these store contexts. Several methods of managing store contexts are known in the art. One method involves creating a store identifier or store ID for each store, and appending the store ID as a parameter in each of the URLs that are called. The URLs would look something like this for the process steps described above:
Step (1) . . . /StoreFrontDisplay?StoreID=c_store1
Step (2) . . . /ProductDisplay?StoreID=c_store1&ProductID= . . .
Step (3) . . . /OrderProcess?StoreID=s_store2 . . .
Step (4) . . . /OrderDisplay?StoreID=s_store2
Step (5) . . . /ProductDisplay?StoreID=c_store1&ProductID= . . .
where c_store1 is the store ID for the channel store and s_store2 is the store ID for the supplier store.
A disadvantage of this approach is that it requires web designers to hard code the store ID into URLs used in the Internet or web application. This additional complexity further complicates modular application design. For example, hard coding URLs in an MVC application may affect the design of each of the model, view, and controller components.
In view of these shortcomings, there exists a need for another method of managing commerce contexts.